API Gatewayパターン

https://scrapbox.io/files/6370d84170733f001eff693a.png

API Gatewayパターンとは？

マイクロサービスシステムを構築する上で採用されるパターン。

クライアント（Web, Mobile, ...）とマイクロサービスの間にAPI Gatewayという単一エンドポイントを置く。

API Gatewayが主にやること

リクエストの適切なルーティング

クライアントからのリクエストを適切なマイクロサービスにルーティングする

認証・認可の集約

認証・認可が必要なマイクロサービスの代わりにセッション管理などを行う

モニタリング

外部からのリクエストを効果的に監視する

流量制限

マイクロサービスに対するリクエストのスロットリングなどを一元的に行う

課金

マイクロサービスの利用料金管理を一元的に行う

プロトコル変換

マイクロサービスに合わせたプロトコル変換などを行う

カプセル化してるからこそできること

API Gatewayのメリット

エントリポイントを抽象化することで、内部のマイクロサービスの変更影響が外に伝わりにくい

SSL接続をAPI Gatewayに任せて、内部をHTTP接続にすることで、SSL接続の負荷を軽減できる

その他いろいろ

API Gatewayのデメリット

API Gatewayが単一障害点になる

正しくスケールしないと、API Gatewayが性能のボトルネックになる可能性がある

API Gatewayで複雑なカスタムロジックがある場合、保守が面倒くさくなる可能性あり

ここは単一責任を重視して作れば回避できそう

API ゲートウェイが単一チームによって開発される場合、開発のボトルネックが存在する可能性あり

さまざまなクライアントのニーズに対応する細かい API ゲートウェイをいくつか使用することをお勧めする理由です。 内部マイクロサービスに取り組むさまざまなチームによって所有されている複数の領域またはレイヤーに API ゲートウェイを内部的に分離することもできます。

これはクライアントごとにBFF用意する的なやつかな？

hr.icon

調査ログ

https://scrapbox.io/files/6370af189c8828001d979377.png

APIゲートウェイは、マイクロサービスアーキテクチャにおける玄関口をしっかりとガードしてくれる「関所」の役割を担ってくれます。また、「関所」機能以外にも、ユーザエクスペリエンスの向上にも寄与する役目も果たします。

https://fujiyamaegg.com/wp-content/uploads/img/20200702234303.png

マイクロサービスアーキテクチャにおけるAPIゲートウェイも同じです。マイクロサービスへの玄関口(エントリポイント)をAPIゲートウェイが提供します。そして、APIゲートウェイが以下の役割を一手に引き受けることで、より効率的に、より効果的にセキュリティ等の役割を担うのです。

リクエストのルーティング/認証・認可/モニタリング/流量制限/課金/プロトコル変換

もし、APIゲートウェイがなければ、どうなるでしょうか？ 外部にさらされるエントリポイントが多くなり、攻撃者にも攻撃できる手数を増加させてしまい、セキュリティリスクが高まります。 また、エントリポイントごとに、セキュリティの対策が必要になり、開発者は、サービス本来の仕事に集中できなくなり、開発組織のアジリティもさげることになるでしょう。

API Gatewayを置くことで、各マイクロサービスをカプセル化することが可能

これにより、マイクロサービスの変更影響を外部に与えにくくなる

APIゲートウェイ のエントリポイントを抽象化することで、ユーザエクスペリエンスも向上します。 もし、クライアントが各サービスから必要な情報を集めて、最終的にクライアントで情報を組み立てるようになるとどうでしょうか？比較的通信速度も遅くなるクライアントとバックエンド側とのやりとりが多くなり、それだけ、最終的にユーザへの応答の遅延が大きくなってしまいます。

並行処理するにもAPI間に処理の依存関係あったら限界あるし

マイクロサービスの数が少ない小さいうちは、API Gatewayのことを考慮しなくてもいい

でもマイクロサービスの数が増えてきたら以下のことを気をつけるべき

クライアント アプリではバックエンドへの要求数をどのように最小化し、複数のマイクロサービスへの頻繁な通信をどのように減らすことができるか

1 つの UI 画面をビルドするために複数のマイクロサービスと対話することは、インターネット上のラウンド トリップの数を増加させます。 このアプローチを使用すると、UI 側の待機時間と複雑さが増します。 理想を言えば、サーバー側で応答を効率的に集約する必要があります。 そうすれば、複数のデータ片が並列に返され、一部の UI では準備ができしだいデータを表示できるため、このアプローチでも待機時間が短くなります。

すべてのマイクロサービスでのセキュリティと承認などのセキュリティと横断的な問題の実装には、開発作業がかなり必要になる場合があります。 考えられる 1 つの方法は、それらのサービスを Docker ホストまたは内部クラスター内に配置して外部からの直接アクセスを制限し、API ゲートウェイなどの中央の場所からそうした横断的な問題を実装することです。

結合：API ゲートウェイ パターンがないと、クライアント アプリは内部マイクロサービスと結合されます。 クライアント アプリでは、アプリケーションのさまざまな領域がマイクロサービスにどのように分解されたかを把握する必要があります。 内部マイクロサービスを進化させてリファクタリングするときに、そのようなアクションは、クライアント アプリから内部マイクロサービスへの直接参照が原因でクライアント アプリに対する破壊的変更を生じさせるため、メンテナンスに影響が及びます。 クライアント アプリには頻繁な更新が必要なので、ソリューションの進化が困難になります。

もしクライアントとマイクロサービスが直接つながってると、、、

マイクロサービスの機能分解の仕方を変更するときに面倒くさくなりそうやな

横断的な問題: パブリックに公開される各マイクロサービスは、認可や SSL などの問題を処理する必要があります。 多くの場合、これらの問題を 1 つの層で処理することができるため、内部マイクロサービスが単純化されます。

全マイクロサービスで、同じことを毎回したくないわ。

https://scrapbox.io/files/6373b14115189a001d76b510.png

たとえば、ECサイトの商品詳細を表示するために、商品情報サービス、レコメンデーションサービス、レビューサービスを利用する必要がある、ということ。この場合アプリケーションの実装によっては並行リクエストを行うのが難しかったり、モバイルアプリケーションの場合は帯域の問題も発生する。（その他にもいろいろあるが割愛）

そこで、アプリケーションとサービスの間にAPIGatewayというレイヤーを追加することで問題を解決する。

つまり API Gateway とはクライアント・マイクロサービス間のネットワークラウンドトリップの低減およびマイクロサービス間のエントリポイントの集約を主な目的としたアーキテクチャのベストプラクティスの一つと言えます。

なお、より特定のアプリケーションを意識して用途を限定・特化させる場合 Backends For Frontends（BFF）とも呼ばれます。